-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix #222181, fix #269998: Dotted rhythms within tuplets #3527
fix #222181, fix #269998: Dotted rhythms within tuplets #3527
Conversation
The basic idea is sound, but I predict it won't work if there are "holes" in the tuplet anywhere to the right of the selected note. By "holes" I am referring to the fact that voices >1, we allow the deletion of rests. Which also leads to problems like https://musescore.org/en/node/270043. And a possible solution there will be to disallow these holes within tuplets in the future, and maybe fix existing scores by filling them with invisible rests on read, so maybe this won't be end up being an issue. But we probably need to consider these together. |
What if this:
were changed to this:
That would make it the same way I calculated |
No, that's no good. Holes to the left of the selected note would cause problems. |
Doesn't version 3.0 solve the problems with holes with the |
Probably so. Haven't really looked into that. |
If I understand correctly, the issue with this is that once a hole is created inside a tuplet, there will be no way to "fill in" the hole by lengthening the duration of the previous elements. And the real problem is that the user was allowed to create a hole in the tuplet in the first place. I agree with you and anyone else who says that deleting rests within tuplets simply should not be allowed. Rests within tuplets are like rests in voice 1. They are required for completeness. |
With this PR and with #3549 we solve all problems for newly created files in MuseScore 2.2. Unfortunately we don't solve import (in particular MusicXML) or old MuseScore 2 files. I think I will merge them both and then let's roll an RC. |
I have done some work on correcting tuplets with missing elements when loading from a file, and it actually works pretty well. The tricky part is figuring out whether to insert a hidden rest into the tuplet before the first known element, and if so, what the duration of that rest should be. This is only tricky because the size of the gaps to either side of the known elements of the tuplet may be larger than what is required for the missing elements. Filling in gaps in the middle of the tuplet is not a problem. Care should be taken to ensure that the tuplet starts on a sensible tick, and that the elements of the tuplet are of a sensible duration. Once we know where the tuplet really starts, the rest (no pun intended) is easy. I believe a reasonable guess for the start of the tuplet is something like
Then, if Of course, a tuplet can be created that starts on a tick that is not divisible by the duration of the tuplet. If such a tuplet is encountered that needs correction, this may figure an earlier start tick for the tuplet, giving the first and last elements a weird duration. But how often is that going to happen? |
See issue 269998.